Fix Oracle Query Generation Issues

Summary

This PR fixes three critical Oracle database compatibility issues that prevented queries with rolling windows, time dimension filters, and subqueries from executing. All fixes maintain backward compatibility with other database adapters.

Issue #1: Invalid AS Keyword in Subquery Aliases

Problem

Oracle does not support the AS keyword before table/subquery aliases. Queries requiring subqueries would fail with:

ORA-00933: SQL command not properly ended

Why It Happened

The query builder was hardcoding the as keyword when generating subquery aliases, which works for PostgreSQL/MySQL but is invalid in Oracle SQL syntax.

What We Did

Modified the query builder to use a database-specific property (asSyntaxJoin) that each adapter can override. Oracle sets this to an empty string, while other databases use "AS".

Example

PostgreSQL (unchanged):

FROM (SELECT ...) AS q_0
INNER JOIN (SELECT ...) AS q_1 ON ...

Oracle (fixed):

FROM (SELECT ...) q_0
INNER JOIN (SELECT ...) q_1 ON ...

Issue #2: TypeError on Time Dimensions Without Granularity

Problem

When using time dimensions for filtering only (without specifying granularity), queries would crash with:

TypeError: Cannot read properties of undefined (reading 'isNaturalAligned')

Example Query

{
  "measures": ["visitors.count"],
  "timeDimensions": [{
    "dimension": "visitors.createdAt",
    "dateRange": ["2020-01-01", "2020-12-31"]
    // No granularity - just filtering
  }]
}

Why It Happened

The code assumed granularity was always present and tried to access properties on an undefined object. Time dimensions used only for filtering don't require granularity.

What We Did

Added a null check before accessing granularity properties. When granularity is not specified, the dimension is used as-is for filtering without grouping.

Result

-- Query now generates correctly:
SELECT count(*) FROM visitors
WHERE created_at >= to_date(...) AND created_at <= to_date(...)
-- No GROUP BY (correct for filtering without granularity)

Issue #3: Invalid Interval Syntax for Oracle

Problem

Queries with rolling windows would fail with:

ORA-17041: Missing IN or OUT parameter at index: 1

Example Query

{
  "measures": ["visitors.unboundedCount"],
  "timeDimensions": [{
    "dimension": "visitors.createdAt",
    "granularity": "year",
    "dateRange": ["2020-01-01", "2022-12-31"]
  }]
}

(where unboundedCount has a rollingWindow configuration)

Why It Happened

The default date arithmetic used PostgreSQL-style interval syntax:

-- PostgreSQL syntax (doesn't work in Oracle)
date_field >= some_date - interval '1 year'

Oracle requires specific functions for date arithmetic instead of the INTERVAL keyword.

What We Did

Implemented Oracle-specific addInterval and subtractInterval methods that use:

• ADD_MONTHS(date, n) for year/month/quarter intervals
• NUMTODSINTERVAL(n, unit) for day/hour/minute/second intervals

Transformation Examples

Before (PostgreSQL syntax):

WHERE date_field >= to_date(:"?", ...) - interval '1 year'

After (Oracle syntax):

WHERE date_field >= ADD_MONTHS(to_date(:"?", ...), -12)

Interval Conversion

Testing

New Test Coverage

Created comprehensive test suite in oracle-query.test.ts with 10 tests covering:

• Basic query generation
• Subquery aliases without AS keyword (multiple scenarios)
• FETCH NEXT syntax instead of LIMIT
• Group by dimensions (not indexes)
• Time dimensions without granularity ✅
• Oracle-specific interval arithmetic ✅

Regression Protection

Added test in postgres-query.test.ts to ensure PostgreSQL continues using AS keyword correctly.

Backward Compatibility

✅ All changes are backward compatible:

• PostgreSQL, MySQL, BigQuery, etc. continue using AS keyword
• The granularity null check works for all database adapters
• Only Oracle uses the new interval arithmetic methods
• All existing queries continue to work as before

Impact

These fixes enable Oracle users to:

• Use time dimensions for filtering without specifying granularity
• Execute queries with rolling windows (trailing, leading, offset)
• Perform time-based comparisons with proper date arithmetic
• Use any query pattern that requires subqueries or date calculations